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Abstract 

The past decade has seen many proposals for future Internet 
architectures. Most of these proposals require substantial 
changes to the current networking infrastructure and end- 
user devices, resulting in a failure to move from theory to 
real-world deployment. This paper describes one possible 
strategy for bootstrapping the initial deployment of future 
Internet architectures by focusing on providing high avail¬ 
ability as an incentive for early adopters. Through large- 
scale simulation and real-world implementation, we show 
that with only a small number of adopting ISPs, customers 
can obtain high availability guarantees. We discuss design, 
implementation, and evaluation of an availability device that 
allows customers to bridge into the future Internet architec¬ 
ture without modifications to their existing infrastructure. 

1. INTRODUCTION 

To be successful in their deployment, designers of new 
technologies must not only solve technical issues (e.g., com¬ 
patibility, efficiency, etc.), but must also offer convincing 
incentives for users to invest time and money to adopt the 
technology. Without proper incentives, achieving substan¬ 
tial real-world deployment is likely a futile effort. 

The deployment of new Internet architectures is especially 
challenging given the millions of hours of effort that have 
gone into building the networks these new architectures are 
designed to replace. Over the past two decades, a num¬ 
ber of new ideas that provide strong technical advantages 
over existing networks and protocols (e.g., mobile IP f2T\ 
and IP multicast ||5]) have been proposed. However, they 
have failed to gain mainstream adoption. The resistance to 
change may be justified, since sizeable financial investments 
and millions of hours spent on training make embracing po¬ 
tentially disruptive changes a less than ideal proposition for 
incumbents. 

Future Internet Architectures (FIAs) aim to solve many 
problems with current-generation networks (e.g., security, 
availability, and scalability). To solve these issues, FIAs 
suggest using radically different paradigms. For example, 
NDN lfT2l provides efficient data delivery by treating data 
(rather than the end-points) as a first-class citizen on the net¬ 
work; MobilityFirst ||25]| designs a mobility-centric network; 


XIA 13 delivers a flexible means of evolving the Internet’s 
core; and SCION ll34ll and NIRA 1^ focus on making 
the Internet more resilient to failures. Despite the appeal¬ 
ing benefits offered by these architectures, they have yet to 
gain mainstream adoption. 

In this paper we present a case study on how to boot¬ 
strap deployment of FIAs by focusing on how to convince 
early adopters. We demonstrate that deployment of a new 
Internet architecture can provide tangible benefits to early 
adopters while requiring minimal changes to existing infras¬ 
tructure during the initial stage of deployment. Our goal is 
to present a feasible adoption plan to gradually (and without 
friction) gain traction. Thus, instead of proposing a generic 
one-size-fits-all plan (i.e., attempting to convince manufac¬ 
turers, ISPs, developers, and end users that they should im¬ 
mediately deploy a particular FIA), we focus on providing a 
single tangible benefit to early adopters: increased network 
availability. For this goal, we propose using FIAs as fallback 
(backup) networks when specific quality of service metrics 
are not met by current Internet paths. We note, however, that 
we focus exclusively on initial deployment. Later steps will 
need other incentives since network availability alone may 
be insufficient to motivate wide-scale deployment. 

Based on simulations, real-world implementation, and 
evaluation, we show that with only a small number of de¬ 
ploying nodes, new Internet architectures, such as NIRA 
and SCION, can transparently improve network availability 
while introducing negligible performance overhead once de¬ 
ployed. Our results provide evidence that the seemingly im¬ 
possible task of deploying a new Internet architecture may, 
in fact, be possible. 

Our contributions are as follows: 

• We describe the value proposition for both end-users 
and ISPs showing that our approach benefits from nat¬ 
ural scalability and wide-scale customer base reacha¬ 
bility (Section^. 

• We design and implement DENA (Device for EN- 
hancing Availability), a bump-in-the-wire device that 
can automatically detect and establish fail-over data 
paths over EIAs, and transparently fail-over to those 
paths when network quality is low. DENA requires 
no user configuration and is designed to be minimally 
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intrusive (Sections|4]and|5ll. 

• We demonstrate, through a full-scale BGP simula¬ 
tion over the CAIDA Inferred AS Relationship dataset 
(45,942 ASes), that a small number (less than five) of 
ISPs deploying a FIA can significantly reduce attacks 
on availability (Section]?]). 

2. RELATED WORK 

We review related work in two overarching themes: in¬ 
creasing network availability and incremental deployment of 
new architectures. 

Several proposals aim to increase Internet availability. 
One avenue towards this objective is through the use of indi¬ 
rection. Andersen et al. HI propose Resilient Overlay Net¬ 
work (RON) to shorten recovery time incurred from BGP 
outages by using an alternate network path through an over¬ 
lay. While the work demonstrates the effectiveness of an 
overlay against BGP outages, it does not describe Internet- 
scale deployment issues where different ISPs can own dif¬ 
ferent parts of the overlay. Our paper discusses deployment 
incentives for possibly competing ISPs. 

Another closely related work is Advertised Reliable 
Routing Over Waypoints (ARROW). In their paper, Pe¬ 
ter et al. ll^ show that by redirecting traffic through tun¬ 
nels, Internet reliability can be enhanced. The authors val¬ 
idate their claim through BGP simulations considering IP 
prefix hijacking attacks. The work herein corroborates the 
results of Peter et al. finding that redirecting traffic to a vic¬ 
tim AS using a tunnel provides higher resilience against pre¬ 
fix hijacking attacks when an adversary targets the victim’s 
IP prefixes. Our simulation (see Section 6.4) encompasses a 
more comprehensive adversary strategy; unlike in ARROW, 
we analyze the case where adversaries are capable of attack¬ 
ing the tunnels as well as the victim AsQ Additionally, our 
paper studies incremental deployment aspects of FIAs, while 
the ARROW paper considers a minimal change that can pro¬ 
vide the greatest increase in availability. For instance, the 
authors do not discuss how and who will manage the Inter¬ 
net Atlas, which is crucial for incremental deployment since 
such an atlas likely requires global coordination between the 
deploying ASes. 

There have been proposals to study incremental deploy¬ 
ability aspects of an architecture. In LISP (The Locator 
Identifier Separation Protocol), Saucez et al. Il28l postulate 
“there must be a clear deployment path that benefits early 
adopters”. Ratnasamy et al. ll24l distilled the properties that 
facilitate the deployment of a new architecture. They pro¬ 
pose the use of IP anycast as the means to access the new ar¬ 
chitecture. We build upon the insights that Saucez et al. and 
Ratnasamy et al. have provided in terms incremental deploy¬ 
ability. However, we avoid using IP anycast as the medium 
to access the new architecture because the use of anycast 

*We have contacted the authors and confirmed the limitations of 
adversary model described in Section 5.8 of their paper (i.e., the 
adversary only announces the prefixes of the victim). 


may preclude ISPs from engaging into a direct business re¬ 
lationship with customers. Instead, in our proposal an inter¬ 
ested customer purchases a value-added service from a de¬ 
ploying ISP, and the ISP would distribute a gateway device 
to access its service. 

3. BACKGROUND AND MOTIVATION 

In this section, we motivate the need for network avail¬ 
ability for ISPs and customers focusing on limitations of the 
Border Gateway Protocol (BGP). 

3.1 Demand for Network Availability 

The ever-increasing dependence on the Internet in our so¬ 
ciety has made availability a critical requirement for network 
infrastructure. We define availability to be the resilience 
against any type of attack or other network fault (e.g., mis- 
configuration) that could prevent or decrease the quality of a 
network connection. 

Due to their core business model (i.e., offering connec¬ 
tivity to customers), ISPs require high network availability. 
We can infer the existence of this demand by analyzing the 
number of multi-homed endpoint ASes on the Internet. Us¬ 
ing a snapshot of the CAIDA Inferred AS Relationships 
dataset m, we observe that 22,386 out of 38,772 (approx¬ 
imately S?*?!]!) endpoint ASes have two or more provider 
ASes. Of these multi-homed ASes, 819 have five or more 
provider ASes. While there are reasons other than availabil¬ 
ity for ASes to be multi-homed (e.g., load-balancing, cost¬ 
balancing), multi-homed ASes are more likely to be accessi¬ 
ble even if one of their BGP paths is unavailable. 

Customers span the spectrum from residential end-users 
to large-scale enterprises to governments. A recent study 
found that residential users are becoming sensitive to qual¬ 
ity of their home Internet connections ll26l . Businesses, es¬ 
pecially those which are geographically diverse, make use 
of Virtual Private Network (VPN) technologies to intercon¬ 
nect sites. For these businesses, the availability of intranet 
resources is tied to the availability of their Internet connec¬ 
tivity. Governments may want to ensure availability of their 
critical infrastructure to control smart grids or to ensure the 
success of online elections (|20l. 

3.2 Degradation of Network Availability 

Several factors may impact network availability on the In¬ 
ternet. These factors range from transient link failures to 
route changes to security vulnerabilities in routing protocols. 
Attacks on BGP are one of the major contributing factors to 
availability issues on the Internet today El. One of the most 
common threats in this context is known as IP Prefix Hijack¬ 
ing. Briefly, a BGP route is defined as an IP prefix and an 
AS-level path which leads to that prefix. Thus, IP prefix hi¬ 
jacking denotes the advertisement (malicious or accidental) 

^The CAIDA dataset was collected on August 1st, 2014. 

^Note that this ratio could be an over-estimate as there are single- 
homed stub ASes without AS numbers. 
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of a prefix which is not authorized for use by an advertis¬ 
ing entity and which diverts the BGP path for that prefix to 
the hijacker. Due to the lack of authentication in BGP mes¬ 
sages, IP prehx hijacking is relatively easy to perform as 
the adversary can announce any prefix of another AS (the 
standard threat model for this type of attack). As a conse¬ 
quence, false injection of update messages can be used to 
launch blackhole attacks HD which hijack and drop traffic 
to compromise availability. Although the following does not 
fundamentally protect BGP against hijacking attacks, we de¬ 
scribe two practices that help in building a more secure path 
in BGP. 

• /24 Prefix Announcements; Due to BGP’s default 
route selection policy, longer prefixes are harder to 
compromise than shorter prefixes ||2irT0ll . However, 
ISPs are hesitant to accept /24 prefix announcements 
pervasively because doing so would dramatically in¬ 
crease the size of routing tables on their border routers. 

• Shorter BGP Paths: Shorter paths are usually more 
resilient than longer paths because border routers typ¬ 
ically prefer routes with shorter AS-Path length. As 
the number of AS hops decreases, there are fewer net¬ 
work locations (routers) from which an attack could 
be launched. Thus, if a route between two end-hosts 
could be divided into multiple shorter path segments, 
it would be more secure than the single longer path 
between the two end-hosts. We confirm this effect 
through BGP simulation in Section|7l 

3.3 Value Proposition for Early Adopters 

Value for ISPs. As early adopters, ISPs that deploy an 
FIA obtain several benefits. First, deploying ISPs benefit 
from higher availability by increasing their resilience to hi¬ 
jacking attacks (see Figure [Q; and, the benefit exist even 
with a small number (see Figure|9]l of deploying ASes. 

The benefit is accrued without sacrificing the scalability 
of BGP routing tables. If every domain were to announce 
/24 prefixes for higher availability (i.e., stronger resilience 
against IP prefix hijacking attacks), the BGP routing table 
does not scale. Instead, in our approach, since only a few 
initially deploying ASes announce /24 prefixes to protect 
their tunnels, the overhead on BGP routing tables is small. 
Furthermore, beyond initial deployment, our approach ben¬ 
efits from natural scalability; as more ISPs deploy the FIA, 
fewer /24 announcements are needed since two contiguous 
ISPs that deploy FIA can communicate directly without a 
/24 announcement. Consequently, we expect the number of 
announced /24 tunnel prefixes to increase during the early 
stage of deployment and decrease as more ISPs deploy. 

Second, there may exist a business incentive for deploy¬ 
ing ISPs to offer high availability to customers of other ISPs 
(e.g., via IP tunnels as described in Section im i. Lastly, ISPs 
can create a niche market for a set of customers who demand 
higher availability than BGP can provide but cannot afford 
dedicated leased lines. 


Value for Customers. Customers may obtain high- 
availability (even if the customer’s local ISP does not pro¬ 
vide such functionality) by subscribing to a remote provider 
via an access tunnel. More importantly, customers can be 
bridged into high-availability architectures without changes 
to software on their local devices or modifications to their 
Internet service. We show one method to achieve this zero- 
configuration setup in SectionH) 

4. OVERVIEW AND REQUIREMENTS 
FOR A HIGH-AVAILABILITY DEVICE 

Guaranteeing benefits under partial deployment alone is 
not sufficient for a successful initial deployment. Customers 
must be able to subscribe to an FIA without carrying out 
any complicated tasks, such as configuring their network de¬ 
vices or updating them to a new network stack—updating 
the network stack on light bulbs, cameras, televisions, refrig¬ 
erators, and other Internet of things devices may be infeasi¬ 
ble. To this end, we develop a bump-in-the-wire interface 
device which we refer to as DENA (Device for ENhancing 
Availability) to be placed between the customer’s network 
and their Internet provider. An alternative approach could 
be to deploy such interface devices at the ISPs themselves 
(this approach is used by Peter et al. ED), completely re¬ 
moving end-user involvement. However, this strategy would 
preclude users from subscribing to the EIA if their immedi¬ 
ate ISP does not deploy it. 

The primary function of DENA is to increase Internet 
availability to its subscriber by leveraging a given EIA as 
a fail-over network. That is, if the IP path between two cus¬ 
tomers (deploying end-points) becomes unavailable, DENA 
would detect the unavailability and automatically fail-over 
to a path through the EIA by encapsulating IP packets. 

To provide high-availability guarantees, DENA devices 
need to implement four functionalities. Eor a given commu¬ 
nication flow between a subscriber and a peer, the DENA 
needs to 7) identify the presence of a peer; 2) if present, es¬ 
tablish EIA path(s) to be used as fail-over; 3) continuously 
measure the packet loss rate of the path(s); and 4) fail-over 
to a path offered by the EIA if necessary. 

Although our design and implementation of DENA re¬ 
mains generic for any EIA that is capable of providing high- 
availability guarantees (e.g., NIRA and SCION), through¬ 
out the following sections, we draw on SCION as the cho¬ 
sen example EIA. We find it useful to focus on one particular 
EIA to keep the discussion concrete and to drive the narra¬ 
tive. In addition, our access to the global SCION testbed 
enables for a thorough evaluation of our implementation. 

Eor space reasons, we do not provide details of the 
SCION architecture in this paper; however, the discussions 
in the following sections should be clear without any prior 
knowledge of SCION (Zhang et al. RtIB . 

4.1 ISP Deployment Model 

To minimize impact on their current infrastructure, ISPs 
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/24 Prefix /24 Prefix /24 Prefix 

Announcement Announcement Announcement 



Figure 1: Three tunnels that are used in FIA deployment. In each 
subfigure, circles marked Di represent ASes that have deployed 
FIA, and circles marked NDi represent non-deploying ASes. 


are likely to deploy a high-availability infrastructure as an 
overlay to their current networks ||2^ . Customers, as well as 
other ISPs will use IP tunnels to bridge into these overlays. 

Hence, constructing reliable tunnels is essential to provide 
high-availability guarantees. To this end, /24 prefix blocks 
are used to reduce the risk of traffic hijacking attacks against 
the tunnels. 

For our deployment strategy, we define the following tun¬ 
nel types (shown in Figure [T]i, and explain how tunnels are 
protected against hijacking by using the practices described 
in Section[32] 

Access Tunnel. A tunnel with which a deploying ISP can 
offer high-availability services to customers whose ISPs do 
not support these features. As shown in Figure[T^, to protect 
the tunnel between A and itself from hijacking, the deploy¬ 
ing AS (Di) announces a /24 prefix that contains the IP ad¬ 
dress used for that tunnel. This announcement reduces the 
probability of an adversary successfully hijacking this tunnel 
if they are multiple hops away from A and Di. 

Inter-site Ttinnel. A tunnel that connects two non¬ 
contiguous deploying ASes over the Internet (see Figure[T]i- 
The ASes need to protect the tunnels that link deploying sites 
from prefix hijacking attacks. Similar to the access tunnels 
above, each of the two ASes announces a /24 prefix block 
that contains the IP address used as its tunnel end-point ad¬ 
dress. 

End-to-end Tunnel. A series of tunnels that consist of 
access tunnels and inter-site tunnels to connect customers A 
and B over the FIA deployment. For instance, in Figure [T] 
the end-to-end tunnel consists of one access tunnel and one 
inter-site tunnel. 

4.2 End-to-End Communication Scenario 

Before describing the design and implementation of 
DENA, we sketch a high-level picture of how an end-to-end 
communication flow would behave in a typical Internet-wide 
scenario shown in Figure |2] 

In this scenario, there are two SCION providers (Provi, 
Prov 2 ) that have deployed gateways (GWi, GW 2 ) to serve 


their SCION subscribers. There are three end-hosts (Hosti, 
Host 2 , Hosts), where Hosti has a public IP address, and 
Host 2 and Hosts are behind a NAT. To enhance their Inter¬ 
net availability, Hosti has subscribed to the SCION service 
from Provi, and Host 2 and Hosts from Prov 2 . All hosts have 
placed DENA devices as bump-in-the-wire on their network 
connection. 

Consider a scenario where Host 2 initiates communication 
to Hosti. Upon receiving a packet from Host 2 , DENA 2 
checks if it knows the peer DENA associated with the des¬ 
tination address of the packets. If it does not know the as¬ 
sociated peer, DENA 2 initiates a Discovery Process (Sec¬ 
tion EB and exchanges bootstrapping information that is 
necessary for constructing SCION overlay paths to the re¬ 
mote peer. In addition, the bootstrapping information con¬ 
tains information necessary for NAT traversal, which we dis¬ 
cuss in Section^ 

A DENA monitors the packet loss rates of the paths (both 
IP and SCION paths) to all of the discovered peer DENAs 
(Section|52]). Whenever the quality of the IP path to a peer 
DENA degrades below a given threshold, and the quality of 
a path provided by SCION is acceptable, all of the flows 
associated with the peer DENA are encapsulated and redi¬ 
rected to the SCION path to ensure continued availability. 

Redirection over SCION is accomplished via a series of 
tunnels using the packet structure shown in Eigure |3] The 
first and last tunnels are access tunnels (see Eigure [T^) be¬ 
tween the DENAs and the SCION gateways. The interme¬ 
diate tunnel is a series of inter-site tunnels (see Eigure (TJi) 
that links the two SCION ASes to which the two end-hosts 
are subscribed. 

In our communication example between Host 2 and Hosti, 
the packets from Host 2 to Hosti traverse from DENA 2 to 
DENAi via tunnels across DENA 2 to GW 2 , Prov 2 to Provi, 
and GWi to DENAi. DENAi removes the tunnel header 
and the SCION header, and forwards the regular IP packets 
to Hosti ■ 


IP Tunnel 

SCION 


Header 

Header 



Data Header 
(e.g., IP+TCP) 


Data Payload 


Figure 3: Packet structure over SCION 


4.3 Requirements 

Previous work in the incremental deployment literature 
|^|28l has discussed desirable properties for an architecture 
to gain adopters. These properties mainly refer to the need 
for incentivized adoption, independence from ISPs that hosts 
buy their Internet connection from, and compatibility with 
existing devices and infrastructure. Based on these proper¬ 
ties, we define the design requirements for our own incre¬ 
mental deployment device. 

Req 1. No Changes to End-hosts: End-hosts should not 
require any modification to make use of the EIA. Rather, 
DENA should operate as an interface between the current 
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Figure 2: An example of end-to-end communication. The destination identifier is implemented as the 5-tuple information. See Section|5] 


Internet and FIA, enabling a smooth transition between the 
two architectures. 

Req 2. Zero configuration: DENA should operate as a 
“plug-and-play” device and should not require any con¬ 
figuration by users. However, similarly to wireless access 
points, a DENA should allow fine-tuning of parameters by 
advanced users. 

Req 3. Robustness: DENA should work under a major¬ 
ity of network configuration scenarios and in the presence 
of packet-modifying or packet-filtering middleboxes (e.g., 
NATs and firewalls). 

Req 4. Autonomous peer discovery: DENA should not re¬ 
quire any additional infrastructure to detect a peer DENA. 
Such additional requirements would create complications 
regarding who would build and maintain the additional in¬ 
frastructure and these complications will hinder incremen¬ 
tal deployment. 

5. DESIGN AND IMPLEMENTATION OF 
DENA 

This section describes the DENA design shown in Eig- 
urelU which shows the major components (discovery pro¬ 
tocol and path management) and the corresponding sections 
where the descriptions for the components can be found. 



Figure 4: Major DENA components. 


5.1 Discovery Protocol 

The goals of the DENA discovery protocol are 7) to au¬ 
tomatically and transparently (i.e., without interfering with 


active data flows) detect the presence of a remote peer and 
2 ) to exchange bootstrapping information that is necessary 
for constructing paths over SCION to the peer DENA. 

Discovery is performed whenever a DENA device detects 
a new communication flow, identified by the 5-tuple infor¬ 
mation (source IP, destination IP, source port, destination 
port, and protocol number) of the packets in the flow. Ports 
are used in addition to the source and destination address 
pairs so that DENAs behind a shared NAT can be distin¬ 
guished and identified. Eor example, in Eigure|2] DENAi 
cannot identify whether the communication flow is being 
forwarded by DENA 2 or DENA 3 based only on the IP ad¬ 
dress because the packets forwarded by both DENAs would 
have the same source IP address, 5.5.5.5. 

Before describing the two parts of the discovery proce¬ 
dure (detection and bootstrapping), we describe the signal¬ 
ing channel that is fundamental to our discovery procedure. 

5.1.1 Signaling Channel 

The most important challenge in DENA detection is to 
construct a reliable signaling channel to the peer DENA 
through which the DENA discovery message is transmit¬ 
ted. Naively, one can define a dedicated UDP or TCP port, 
and send a discovery message to that port. Although the ap¬ 
proach may work for general cases, it can be problematic in 
the presence of middle-boxes such as firewalls and intrusion 
detection systems. Additionally, users may be required to 
perform manual configurations on such devices, which vio¬ 
lates the zero-configuration requirement from Section iTj] 

Alternatively, we suggest constructing the signaling chan¬ 
nel using end-hosts’ traffic. This type of channel has been 
widely studied in network steganography with two generic 
approaches m-- 1) manipulating structure of packet streams 
(i.e., temporal variation in packet transmission times); and 
2 ) manipulating packet headers, such as IP and TCP head¬ 
ers. Although the signaling channel constructed via the for¬ 
mer method tend to be more robust against various middle- 
boxes, it unavoidably introduces undesirable delay and jitter 
into end-hosts’ communication ini. Thus, we use the latter 
method to construct the signaling channel. 
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To make DENA compatible with any IP based protocols, 
we use the TTL and Identification (IPID) fields in the IP 
header. Note that while we are hiding signals inside the 
IP header, this is done for compatibility rather than for se¬ 
curity. That is, our objective is not to prevent an observer 
from seeing that the channel is being established, but rather 
to prevent the signaling messages from being parsed (possi¬ 
bly incorrectly) by the destination device in case a DENA 
device is absent. 

TTL. Although 255 is the literal maximum value of the TTL 
field, IP paths on the Internet are generally shorter than 64 
router hops (with 64 being the recommended initial TTL 
value EH). Hence, it is possible to decode the values that 
the sender has chosen if the initial TTL values are chosen to 
be at least 64 units apart. Since there can only be tuples of 
at most three TTL values that are 64 units apart from each 
other, we define three signals A, B, C from three TTL values, 
64, 128, 192, respectively. 

IPID. Since the use of the IPID field remains unspecified for 
unfragmented packets, the field can be used to embed hidden 
signals El. We define three hidden signals from the IPID 
values so that the DENA detection procedure can be used 
with both TTL-based and IPID-based signals. 

We choose three sets of IPID values whose 12 most signif¬ 
icant bits (MSBs) are 0x001, 0x7PP, OxLPL as signals A, B, 
and C, respectively. The values are chosen to be maximally 
spaced apart (without including IPID value of zero) to pre¬ 
vent operating systems that increment the IPID value by one 
for each transmitted packet, from accidentally transmitting 
all three of our defined signals during the DENA detection 
procedure. In addition, there are 16 IPID values that corre¬ 
spond to a hidden signal. Although fragmentation is discour¬ 
aged in practice (for efficiency reasons), fragmented packets 
do exist on the Internet 1^ . The last four bits can change 
to repeat our signals even when some of the IPID values are 
used for fragmented packets. 

5.1.2 DENA Detection 

Lor detection, every DENA device periodically an¬ 
nounces the discovery messages and responds to the received 
discovery messages with the bootstrapping information (de¬ 
fined in Section l5.1.31 l. 

The discovery message is defined as a sequence of signals 
known to all DENAs a priori (See Table [T] in Section |6]l. 
Because the message is a sequence of hidden signals, the 
message is encoded into a stream of consecutive packets. 
Hence, when announcing the discovery message, a DENA 
modifies the TTL and the IP ID fields of the packets that it is 
forwarding. In our design, both TTL and IPID fields are used 
to encode the same hidden signals to enhance the robustness 
of DENA detection. Thus, even when one of the fields gets 
scrubbed by middle-boxes, DENAs can use the other signal 
to decode the discovery message^ 

"^During our experiment, we encountered a middle-box that scrubs 
the TTL fields but keeps the IPID fields intact for TCP flows. 


In addition to periodically emitting the discovery mes¬ 
sage, DENA listens for the discovery message by exam¬ 
ining the TTL and IPID fields from streams of incoming 
packets. Identifying the discovery message from a stream of 
packets is a challenge because the Internet, as a communica¬ 
tion channel, may reorder, lose or duplicate packets. In fact, 
the decoding problem at hand is similar to the well-known 
insertion-deletion channel problem to which an efficient de¬ 
coding algorithm is not yet found M- 

Combinatorial methods, which compute the difference be¬ 
tween the transmitted and received messages, have been 
studied for decoding under insertion-deletion channel. Edit 
distance (i.e., Levenhstein distance ifTTlH provides a metric 
to compare the difference between the two messages based 
on the minimal number of edits (insertion, deletion, replace¬ 
ment) that are necessary to transform one message to the 
other. In our design, DENA concludes the presence of a 
peer if the edit distance between the discovery message and 
the received message is below the detection threshold value 
(i.e., fewer number of edits than the detection threshold). 

A DENA may falsely conclude the presence of a peer 
DENA. On one hand, a DENA may fail to detect a remote 
peer that is present (i.e., false negative) because the Internet 
may drop or reorder the discovery message that the DENA 
sends to its peer. On the other hand, a DENA may falsely 
detect a peer that is not present (i.e., false positive) due to 
the IPID fields in a stream of packets accidentally having the 
right sequence as the discovery message. There are trade¬ 
offs between these two probabilities, and they depend on 
the decoding parameters, such as the length of the discov¬ 
ery message as well as the detection threshold value. 

When the decoding is solely based on edit distance, the 
false positive probability can be high. To lower the false 
positives, we place a light-weight pre-filter that checks the 
approximate structure of the received message before com¬ 
puting the edit distance. The pre-filter lowers the false posi¬ 
tive probability while increasing the probabilities of the false 
negatives. Eor an example design of the pre-filter and the de¬ 
tection error analysis, see Section| 6 l 

5.1.3 DENA Bootstrapping 

After detecting the presence of a peer, bootstrapping in¬ 
formation that is necessary for constructing SCION paths is 
transmitted. The information can be transmitted through the 
signaling channel described in Section lS.l.ll However, since 
the signaling channel has very small capacity (i.e., log 2 ( 3 ) 
bits per packej§), the channel’s capacity is too small to send 
the bootstrapping information, (i.e., 10 bytes are needed for 
SCION). 

Alternatively, we define an out-of-band control-packet 
that is generated by the DENAs to communicate bootstrap¬ 
ping information. Since a DENA has detected the presence 
of a peer, it can send a dedicated packet knowing that it will 

^Assuming perfect channel that does not lose, reorder, or duplicate 
packets. 
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be parsed and discarded by the peer DENA before the packet 
reaches the peer end-host. Hence, the control packets do not 
disrupt end-host communication. 

The control packet must be carefully constructed so that 
it can be reliably delivered to the intended DENA, passing 
through middle-boxes that may be present. To this end, con¬ 
trol packets are created by duplicating the end-hosts’ pack¬ 
ets. Eor UDP packets, the fact that end-hosts’ packets can 
reach the destination ensures that the control packet would 
be able to reach the peer DENA. Eor TCP packets, middle- 
boxes have no choice but to accept the control packets, as it 
cannot tell whether the control packets are generated due to 
routine packet re-transmissions in the TCP protocol. 

After duplicating end-host’s packet, the payload (after the 
IP and transport header) is modified as follows. A DENA 
identifier message is added at the beginning to indicate that 
the message is a DENA control packet. Then the message 
type to indicate the type of the control message and the mes¬ 
sage payload are added. 


the incoming packet counter. Einally, using the four counter 
values, A computes the packet loss rate, which is defined to 
be the maximum of the loss rates between incoming and out¬ 
going paths. 

When computing the packet loss rate, the difference in 
counter values from current and past measurements are used. 
Thus, the two measurement points A and B do not need 
to synchronize the starting time at which both points start 
counting outgoing and incoming packets. 

Eor our context, the two measurement points would be 
the pair of DENAs. In addition, the measurement request 
and reply packets needed for the measurement are imple¬ 
mented using the DENA control messages described in Sec¬ 
tion |5T21 

The MPLS measurement approach offers several advan¬ 
tages for our implementation. Eirst, it is light-weighj§ sec¬ 
ond, synchronization between two DENAs is not necessary; 
third, two-way channel delay can be computed with only a 
small additional overhead (see Erost et al. ||6l for details). 


5.2 Path Management 

To achieve a high level of availability, it is necessary to pe¬ 
riodically monitor the status and quality of both the IP path 
and the SCION paths. Whenever the quality of the IP path 
degrades below a threshold, communication between end- 
hosts is switched over to a higher-quality path offered by 
SCION. Eurthermore, even after the switch, the IP path is 
constantly monitored so that the communication may switch 
back to the IP path after it is again reliable. 

5.2.1 Path Quality Measurement 

A DENA periodically measures packet loss rates for both 
IP and SCION paths to all peer DENAs found during the 
DENA Discovery Procedure. Unlike the DENA Discovery 
Procedure, which is performed per flow, path measurement 
is done per peer DENA. An advantage of this approach is 
that it enables more accurate measurement, since a DENA 
can have many associated flows (e.g., multiple concurrent 
TCP connections to an HTTP server). 

Measurement of the Active Path. Eor path quality mea¬ 
surement of the active path, we rely on data packets from 
end-hosts that are flowing between a pair of DENAs. We 
adopt a packet loss measurement method that has been used 
for quality measurements in MPLS networks 1^. Briefly, 
the proposal uses a pair of measuring points each of which 
maintains two counters for counting incoming and outgoing 
packets, and computes packet loss rates based on the four 
counters. 

Specifically, the measurement proceeds as follows be¬ 
tween two measuring points, A and B. Eirst, A initiates the 
measurement by sending a request message to B with the 
outgoing packet counter value at the moment that the re¬ 
quest is made. Then B replies to the request with the value of 
the incoming packet counter as well as its outgoing packet 
counter value. Upon receiving the reply, A marks its value of 


Measurement for Fail-over Paths. The quality of the 
fail-over paths must be monitored so that the DENA can 
ensure that the fail-over paths are healthy when attempting 
to send data traffic over one of these paths. However, the 
passive MPLS measurement cannot be used directly for the 
fail-over path since no data traverse them. 

To overcome such problem, we sample the traffic flowing 
though the active path and transmit this traffic over the fail¬ 
over paths. Since the loss rate of both outgoing and incoming 
traffic are necessary, we need bi-directional traffic flowing 
through the fail-over paths. Hence, the two DENAs need to 
coordinate the time when data traffic through the active path 
is replicated on the fail-over paths. 

To coordinate the measurement intervals between two 
DENAs, we use the DENA control channel (Section B.1.31) . 
Two DENAs exchange a “start message” to start the mea¬ 
surement and a “stop message” to stop the measurement. An 
advantage of this approach is that it requires no form of time 
synchronization, which can be difficult to achieve without 
introducing additional complexity. 



Figure 5: State machine for the Path Quality Measurement. 


Eigure|5]shows the state machine for the path quality mea- 

^The measurement points keep trivial amount of states—the four 
counter values for the previous measurement. 
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surement, which consists of three phases. The Initiation 
Phase is started when DENA transmits the Start message 
and is completed when the initiating device receives a Start 
ACK message from a peer. The initiating and responding 
DENAs are decided based on the ID values that they ex¬ 
change during the bootstrapping phase. 

During the Measurement Phase, each DENA performs 
the measurement to compute the packet loss rates of the fail¬ 
over paths. Once the measurement is complete, the two peers 
listen for Stop messages that are used for terminating the 
measurement. In addition, both DENAs maintain timers to 
mark the end of the measurement period. A DENA sends a 
Stop message to its peer when the timer expires. Upon suc¬ 
cessfully exchanging the Stop and Stop ACK messages be¬ 
tween the two DENAs, the path measurement cycle is com¬ 
pleted. 

In addition to marking the end of an measurement inter¬ 
val, the Stop and Stop ACK messages serve another pur¬ 
pose. These messages contain the packet loss rates and their 
decisions regarding which path to use to forward end-hosts’ 
data traffic. 

Lastly, similar to the TCP connection tear-down proce¬ 
dure, we implement a timeout state (i.e., TimeJWait state) so 
that a DENA that sends the Stop ACK is sure that the peer 
DENA has received the Stop ACK message. 

Path Keep-Alive based on Active Probing In cases 
where a path drops all packets (e.g., link failure), our mea¬ 
surement does not work. To cope with such failures, a 
DENA periodically exchanges ICMP probe messages with 
the peer DENA through all available paths. If a DENA does 
not receive any response for consecutive probe messages 
from a path, the DENA considers the path to be unavail¬ 
able. Additionally, the DENA immediately terminates the 
ongoing path measurement and starts a new measurement. 

5.2.2 Path Selection 

Path selection is performed whenever a path measurement 
is completed (when DENA reaches the Done state). A new 
path is selected as follows: 1) whenever the loss rate of the 
IP path is lower than the threshold, a DENA chooses the IP 
path, 2) if the loss rate is higher than the threshold and if 
there is a SCION path that has lower packet loss rate than 
the threshold the SCION path is chosen, 5) if none of the 
paths has lower packet loss rate than the threshold, the path 
with the lowest loss rate is chosen. 

5.3 Implementation 

The proof-of-concept prototype of the DENA consists of 
3K lines of C code. The implementation runs on Linux, us¬ 
ing the Netfilter Queue (nf queue) Library ll^ which en¬ 
ables IP tables firewall decisions to be made in user-space. 
We use the nf queue library, which allows packet modifi¬ 
cation before accepting a packet, to manipulate packets and 
encode the hidden signals. DENA control messages also 
make use of the library. 


6. EVALUATION OF DENA DESIGN 

We validate our design and implementation of DENA 
through simulation and real-world evaluation over the 
SCION testbed^ More specifically, we are interested in 

1) ensuring our implementation meets design objectives; 

2 ) confirming that the EIA measuring the false positive and 
false negative probabilities during DENA detection; and 

3) evaluating the effectiveness of the path quality measure¬ 
ment described in Section l5.2.1l 

6.1 Conformance to Requirements 

DENAs are deployed between the customer’s end-hosts 
and their Internet connection, which requires no changes to 
the end-host itself (Req 1). DENAs do not require any man¬ 
ual configuration (such as IP addresses) by users. Once con¬ 
figured by ISPs, DENAs are designed to be plug-and-play 
(Req 2). 

Although DENAs generate control packets, these pack¬ 
ets by design are not forwarded to end-hosts. Thus, end- 
hosts should never receive or need to parse control pack¬ 
ets. DENAs can work in the presence of various types of 
middle-boxes and NATs, which satisfies the robustness re¬ 
quirement (Req 3). Eurthermore, as control packets (which 
are opportunistically duplicated from end-host traffic) are in¬ 
distinguishable from data packets at the IP and transport lay¬ 
ers, they can be forwarded by middle-boxes without being 
filtered. 

Einally, the DENA Discovery Procedure satisfies the self- 
discovery requirement (Req 4), since it does not require ad¬ 
ditional infrastructure for peer DENA detection. 

6.2 DENA Detection Procedure Analysis 

As discussed in Section B. 1.21 the proposed DENA de¬ 
tection procedure is subject to both false positives (i.e., de¬ 
tecting a DENA when it is not present) and false negatives 
(i.e., not detecting a DENA when it is present). In this sec¬ 
tion we evaluate false positive and false negative probabili¬ 
ties through simulation. We summarize the parameters that 
we use for the DENA simulation and implementation in Ta¬ 
ble □ 

Eigure |6] shows the probability that a DENA fails to de¬ 
tect the presence of a peer as packet loss rates are varied 
at 1% increments from 0% to 10% within five attempts of 
DENA detection. Eor precision, we take the average of one 
million runs for each fixed packet loss rate. As expected, 
the false negative probability increases with increased packet 
loss rate. In addition, the false negative probability is higher 
when the pre-filter is used or when the lower edit distance 
threshold value is used. 

Eurthermore, false negative probability decreases expo¬ 
nentially as the DENA Detection is performed multiple 
times (not shown in Eigure). Eor example, at 10% packet 
loss rate, there is about 35% chance that a DENA fails 

’The topology of the testbed can be found at 

https://polybox.ethz.ch/public.php?service=files&t=ldlc 
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Discovery 

Message 

ABABABABCCCCCCCCABABABAB 

Pre-Filter 

1. Divide decoded message into 3 blocks of 

8 signals. 

2. Check if there are at least three A-signals 
and three 6-signals each in the first and the 
third blocks 

3. Check if there are at least six C-signals 
in the second block 

Edit distance 
Threshold 

3 or 5 

Meas. Interval 

1 seconds 

Meas. Period 

1 seconds 

Path Switch 
Thresh. 

5% Packet Loss 


Table 1; Parameter settings for the DENA simulation and imple¬ 
mentation. 


to detect a remote peer if the detection procedure is per¬ 
formed only once for the case with pre-filter and the detec¬ 
tion threshold of three. However, when the detection proce¬ 
dure is repeated for five times, the false negative probability 
decreases to about 0.6% as shown in Figure |6] 



Figure 6: Probability that DENA fails to detect it a remote peer 
within five attempts of the detection procedure. 

A trade-off exists between missed detection and incorrect 
detection. That is, the settings that have yielded higher false 
negative probability have lower false positive detection prob¬ 
ability. To simulate this effect, we input a stream of packets 
that consists of one million packets where a random IPID 
value is chosen for each of the one million packets. Then, 
we check whether a DENA would incorrectly identify the 
presence of a peer within the stream. We repeat this simu¬ 
lation 10,000 times to get an estimate of the false positive 
probability, and the results are summarized in Table |2] 

The false positive probabilities are lower when a pre-filter 
is used. Also, the false positive probabilities are lower for 
the lower threshold value as the received message has to be 
closer (i.e., fewer number of edits) to the discovery mes¬ 
sage. Note that during regular operation, DENA would not 
attempt more than a few detection attempts. Thus, the val¬ 
ues in Table |2]represent a worst-case scenario. Eor our next 
analysis, we use the threshold value of 5 with the prefilter as 
it strikes the balance between EP and EN probabilities. 


Threshold 

w/ prefilter 

w/o prefilter 

3 

5 

0.02% 

4.4% 

0.03% 

11.8% 


Table 2: False positive probability of tbe DENA Detection Pro¬ 
cedure against a stream of one million packets with random IPID 
values. 

6.3 Path Switching Based on Path Quality 
Measurement 

The purpose of this experiment is to confirm that our 
DENA implementation can react to the change in path qual¬ 
ity and switch the end-hosts’ traffic to alternate paths if nec¬ 
essary. Eor the experiment setup, we deployed two DENAs 
on the SCION global testbed. One was placed at ETH 
Zurich (AS6) and the other at CMU (AS 14). We placed a 
WANem Emulator 12^ on the IP path from AS6 to AS 14, 
which allowed us to introduce arbitrary packet loss rates into 
the IP path. 

We deploy an end-host that runs an HTTP server in AS 14, 
and deploy an end-host that downloads (via the wget appli¬ 
cation) a large file from the HTTP server in AS6. At ap¬ 
proximately 80 seconds into the file download, we introduce 
10% packet loss on the IP path, and then remove the packet 
loss at around 110 seconds. 

At the end-host in AS6, we record the throughput of the 
file download as well as the data rates on both paths to vali¬ 
date our implementation. Throughput information is plotted 
in Eigure |7] showing the change in throughput over time as 
for the wget application as well as the two paths. 

Initially, the end-host’s traffic flows through the IP path. 
In addition, there is about 10% of the traffic flowing through 
the SCION path for measuring the path loss rate of the fail¬ 
over path. When 10% packet loss is introduced on the IP 
path at around 81 seconds, the two DENAs switch over to 
the SCION path about 2 seconds into the degradation. The 
switch can be verified by the increase in throughput at the 
SCION path to that of the actual file-transfer rate as well as 
the decrease in throughput at the IP path. 

Einally, after the 10% packet loss is removed from the IP 
path, the DENAs move the end-hosts’ traffic back to the IP 
path after about two seconds of delay. This test was repeated 
5 times obtaining comparable results in each iteration. 

7. DEPLOYMENT ANALYSIS 

In the previous section, we have shown that DENA can 
improve the availability of the end-hosts’ connections de¬ 
spite changes in network conditions (e.g., when there is a 
packet loss in the Internet). In this section, we evaluate the 
availability benefits of a EIA when there are adversaries that 
perform IP prefix hijacking attacks. In addition, we analyze 
the benefits that deploying ISPs could accrue. 

To evaluate the deployability and availability benefits of a 
EIA, we perform series of BGP simulations by extending the 
BSIM simulator ifT^ . where the BGP paths are computed us- 
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Figure 7: Path switching based on measured path quality. 

ing route selection based on the standard BGP routing poli¬ 
cies (Gao-Rexford Model G]). As our topology dataset, we 
use a recent snapshot of the CAIDA Inferred AS Relation¬ 
ship dataset. 

7.1 Tunneled Paths Resilience 

The announcement of /24 prefixes for the tunnels offers 
protection of the tunnels against prefix hijacking attacks; 
however, the /24 prefix announcements cannot prevent all 
hijacking attacks. As the length (in AS hops) of the tun¬ 
nel increases, the resiliency against hijacking decreases. In 
this section, we investigate the benefit (i.e., resilience against 
prefix hijacking attack) that a path constructed using a series 
of short tunnels can provide over a single BGP path. 

For our study, we use the following notation: 

{ASx, ASy): BGP path (list of ASes) between ASx and ASy, 
KAS'j;, ASj,)|: length (expressed in AS-level links) of 
{ASx, ASy) path, 

Tn' number of deploying ASes ASi, AS2, ■■■, ASt^^j that form 
the overlay end-to-end tunnel, 

Tl- length of the longest tunnel segment (i.e., maximum 
|(A5i,AS'i+i)| fori € [TTiv - 1]), 

Lbgp- length of the BGP path between AS*! and AStj^ 
(i.e.,|(ASi,A5T„)|), 

Lt- length of the tunneled path betweeen ASi and ASt^j 

Tjv-l 

(i.e., E |(A5i,ASi+i)|). 

i=l 

We assume that the first node of an end-to-end tunnel path 
(AS"!) is the source while the last (AS'tn) the destina¬ 
tion. Then, Lbgp expresses the length of the BGP path be¬ 
tween source and destination. We also assume that traffic 
from source to destination over the end-to-end tunnel tra¬ 
verses overlay nodes AS 2 , AS^,AStn-i in that order. 
The tunnel’s path on an AS-level is a concatenation of BGP 
paths: {ASi,AS 2 ), {AS 2 , AS 3 )..., [ASr^y-i, AStJ- 
For our simulation, we consider two adversary strategies 
designed to hijack traffic from source to destination: 1 ) 
weak adversary which announces only the destination’s pre¬ 
fix, and 2 ) strong adversary which announces all prefixes of 
AS 2 ,ASz, ..., AStn- in both cases an adversary launches 


attacks from a randomly compromised AS, however he can¬ 
not compromise ASes on the path between source and des¬ 
tination. Note that ARROW ll2^ only considers the weak 
adversary model and does not consider the strong adversary 
model. 

In this experiment, we simulate 8 scenarios by varying 
Tn, Tl, and Lbgp to analyze the resilience that tunnels can 
provide against prefix hijacking attacks. For each scenario, 
while incrementing the number of adversarial ASes from 1 
to 7, we construct and simulate 1000 random and unique 
tunnel deployments, where Ti and Tn are randomly chosen 
from multi-homed stub ASes and the other tunnel nodes are 
chosen from all other ASes@ 

Figure [8] summarizes the results of our simulation. In 
each graph in the figure, the a:-axis represents the number 
of adversaries (varied from 1 to 7) and the y-axis represents 
probability values that an attack on the tunneled path will be 
successful. The two figures on the left show the hijack prob¬ 
ability of the tunneled path for source and destination AS 
pairs that are four BGP hops apart {Lbgp=A)', and, on the 
right five BGP hops apart {Lbgp=^)- Moreover, the upper 
two figures show the results against weak adversaries while 
the lower two figures show the results against strong adver¬ 
saries. Lastly, each plot also shows hijack probability for the 
BGP paths (green line with plus markers). 

Our results show that the hijack probability increases as 
the number of adversaries increases and that the probability 
is higher for the strong adversary model than the weak adver¬ 
sary model. Furthermore, against the weak adversary model, 
the probabilities of hijacking the tunneled paths are similar 
for the two cases that have the same tunnel segment length 
(i.e., Tl) but different total length (i.e., Lt )—on the upper 
two figures, the purple lines with diamond makers and the 
red line with inverted triangle markers almost overlap with 
each other. This is because the weak adversary model can 
only attack the last tunnel segment (i.e., {Tn-i, Tn) as the 
weak adversaries only announce the prefix of the destination 
(i.e., Tn)- 

The results show that the tunneled paths have lower hi¬ 
jack probability than the BGP paths even if the length of the 
tunneled path (i.e., Lt) is longer than that of the BGP paths 
(i.e., Lbgp)- But, the result also shows that if the length of 
the tunneled paths becomes too long (e.g., twice the length 
of the BGP paths), the tunneled paths become more suscep¬ 
tible to hijacking attacks. However, in practice, it is highly 
unlikely that the tunneled paths would be twice the length of 
the BGP paths. 

Lastly, the results show that the composition of the tun¬ 
neled path affects the resilience against prefix hijacking at¬ 
tacks: a tunneled path that is composed of shorter individ¬ 
ual segments is more resilient than a path that is composed 
of longer individual segments. For the two cases where 


° To build more confidence of our results, we have run four inde¬ 
pendent sets of 1000 deployments for all 8 scenarios and confirmed 
that the results were similar across the four sets. 
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Figure 8: Probability of hijacking BGP and FIA paths under four tunnel settings while varying the number of adversaries. The upper and 
lower halves show the results for weak and strong adversary models respectively; and the left and right halves show the results for Lbgp = 4 
and Lbgp = 5, respectively. 


Lt < 6, the hijack probability is significantly lower when 
the length of the individual tunnel is kept shorter. In Fig¬ 
ure [H this can be seen by comparing the blue line with ’x’ 
markers and the purple line with diamond markers. More¬ 
over, the result shows that the tunneled paths that have 
longer total length but shorter individual tunnel segments 
(i.e., Lt < 8, red lines with inverted triangle markers) is 
more resilient than the tunneled paths that have shorter total 
length but longer individual segments (i.e., Lt < 6, blue 
lines with ’x’ markers). 

7.2 Potential Customer Base 

In this section, we investigate the proportion of multi¬ 
homed stub ASes that are A-hops (i.e., Tl = N) away 
from any of the deploying ASes as we vary the number of 
ASes which deploy the FIA. This experiment should assist in 
quantifying the potential customer base (measured in num¬ 
ber of ASes) as the FIA deployment increases. 



Figure 9; Proportion of ASes that can communicate over FIA. 


would be at most N BGP hops (i.e., Tl = N). Then, for 
all multi-homed stub ASes, we evaluate the number of ASes 
that are within N hops from any of the FIA deploying ASes. 
The two steps are repeated 5,000 times, and we report the av¬ 
erage in Figure |9l which shows the proportion of the ASes 
that could be reached within N hops from the FIA deploy¬ 
ment as number of deploying AS changes from 1 to 20. 

Our results show that for higher values of Tl, a larger 
portion of the multi-homed stub ASes were within the reach 
of the deploying ASes. Combining the results from Sec¬ 
tion [TTl we can conclude that for large values of Tl, de¬ 
ploying ASes obtain larger customer-base at the expense of 
availability guarantees against prefix hijacking attacks. Con¬ 
versely, when offering higher availability guarantees, the 
customer-base becomes much smaller (i.e., Tl = 2 ). 

As expected, the number of deploying ASes increases 
with the size of customer base. In fact, when there are 20 
deploying ASes, the customer-base nearly spans across the 
entire Internet for the cases with Tl >4. In addition, even 
with only one deploying AS, there are multi-homed stub 
ASes that could benefit from the FIA deployment, and for 
the cases with Tl > 4, more than half of the multi-homed 
stub ASes could access the FIA deployment within Tl hops. 

Lastly, Figure |9] offers another interesting observation— 
reduced benefit (in terms of increase in customer base) as 
more ASes participate in FIA deployment. This can be in¬ 
ferred from the gradient of the plots, which tends to zero as N 
increases. Hence, the result suggests that beyond the initial 
phase of the deployment, a different incentive model may be 
necessary to further drive the FIA deployment. 

8. DISCUSSION 


In this experiment, we randomly choose ASes to deploy 
the FIA such that the distance between deploying ASes 
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8.1 Practical Implications on Deployment 



















NAT Implications. As discussed in Section l431 a DENA 
should work in the presence of middle-boxes such as NATs. 
When a DENA is placed in-between a NAT and an end-host 
(see DENA 2 in Eigure|2]i, communication over the SCION 
path may not work. Eor instance, when the communication 
between Hosti and Host 2 in Eigure|2]is carried out through 
the SCION path, DENA 2 cannot deliver Hosti’s packets to 
Host 2 without being given Host 2 ’s internal address. 

To address this problem, when DENA 2 and DENAi ex¬ 
change bootstrapping information during the DENA Dis¬ 
covery Process, DENA 2 includes the private address of 
Host2. 

Another problem is the communication between GW 2 
and DENA 2 . Because of NAT, GW 2 cannot send a packet 
to DENA 2 before DENA 2 starts forwarding packets via 
SCION. To avoid this problem, DENA 2 periodically ex¬ 
changes keep-alive messages to its assigned gateway, per¬ 
forming NAT hole-punching. Since the DENA itself does 
not have an IP address, it borrows one of the IP addresses 
it has learned from the end-hosts to perform the hole- 
punching. 

MTU Implications. The measurement and correct con¬ 
figuration of MTU size is critical for any scheme that re¬ 
quires encapsulation, such as the tunnels used in our system. 
When end-hosts perform the path MTU discovery protocol 
(PMTUD HD), DENA can respond with an MTU size small 
enough to provide enough space for encapsulation. In the 
event that an end-host does not respond to PMTUD mes¬ 
sages (fewer than 10% of devices do not Ea), packet frag¬ 
mentation would be required, increasing the complexity. 

8.2 Device Configuration and Distribution 

Although DENA does not require any configuration by 
end-users, it requires configuration by ISPs prior to distribu¬ 
tion to customers. Configuration would include information 
necessary for bootstrapping the DENA into the EIA deploy¬ 
ment (i.e., in case of SCION, this includes SCION ISD ID, 
AS AIE0, and IP address of the gateway that a DENA would 
contact to access the SCION network). We note that such 
configurations are common in today’s Internet when ISPs 
distribute cable or DSL modems to their subscribers. In ad¬ 
dition, for customers that already have access devices (i.e., 
cable or DSL modems), the firmwares of these devices could 
be updated to support DENA functionality. 

8.3 Applicability to Other FIAs 

The DENA is a generic device that creates tunnels to in¬ 
terconnect two EIA deploying islands. Hence, it is possible 
to use DENA for other EIAs, as long as tunneling can be 
used to interconnect two EIA deploying islands. The im¬ 
portant part in bootstrapping a EIA is to identify the proper 
incentives for the early adopters. Eor instance, for more effi¬ 
cient distribution and access to the content to early adopters, 

^In SCION, each AS is identified by the ID of the isolation Domain 
(ISD) that the AS is in as well as the identifier of the AS (AID). 


NDN could be deployed. In NDN deployment, DENA 
would translate user data requests into an interest packet and 
send it to the NDN deployment. When the requested data 
arrives at the DENA, it delivers the data to the user. 


We have motivated, designed, and evaluated an incre¬ 
mental deployment strategy for Euture Internet Architec¬ 
tures. Through both simulation and real-world implemen¬ 
tation and testing, we demonstrated tangible availability im¬ 
provements for deploying ISPs with comparatively little de¬ 
ployment cost. Our evaluation used SCION to assess the 
feasibility of our proposal, but the proposed incremental de¬ 
ployment strategy remains compatible with other EIAs. 

While availability alone will likely be insufficient to moti¬ 
vate full wide-scale deployment, this paper focuses on con¬ 
vincing early adopters to use a new architecture. Once a 
base set of ISPs and customers have deployed a EIA, a new 
strategy may be necessary to encourage a majority of ISPs to 
deploy. Eor example, the next set of deploying users could 
be interested in mobility or content-centric networking, but 
such analysis is left open to future research. 
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